Increasing interest and demand in performing transactions electronically over a data network, particularly over the Internet, has created a demand for secure electronic communication. For a transaction to be secure, e.g., an online purchase or an electronic banking transaction, messages exchanged between two parties should remain private and originate from a trusted source. The first issue can be addressed by data encryption, for example using symmetric or asymmetric keys known only to the sender and receiver of a secret message.
The second issue can be addressed by message signing, for example using asymmetric public key signing algorithms, in which a sender of a message generates a signature using a private key on a message to be verified, while everybody receiving the message can verify its authenticity by means of an associated public key.
In some situations, however, a sender of a message wants to remain anonymous with respect to a receiver or verifier of a message while still proving that he or she possesses the required authorization for a particular operation.
For example, a user of a computer system may want to prove that he or she is running a secure operating system in order to be granted access to a closed network, e.g., a company internal local area network (LAN or intranet). Another example would be a user belonging to a certain group, e.g., a subscriber of a particular website, that wants to prove membership before he or she is granted access to resources on this website without disclosing his or her identity.
In order to achieve such and similar goals, the Trusted Computing Group (TCG) has designed a framework for allowing trusted computing. An important part of this framework are so-called trusted platform modules (TPM), which are hardware chips integrated into a computer system and which allow, among other things, secure storage of encryption keys and performing of cryptographic operations. The TPMs operate in a black-box fashion, i.e., the host into which a TPM is integrated cannot manipulate its mode of operating. This protects the TPM, for example in case the platform is infected by some malicious software, also known as viruses.
The framework together with the associated TPMs is described in more detail in two documents titled “TCG Specification Architecture Overview, Specification, Revision 1.2” and “TCG Infrastructure Working Group Reference Architecture for Interoperability (Part I), Specification Version 1.0, Revision 1” by the Trusted Computing Group, Incorporated available at https://www.trustedcomputinggroup.org/downloads/specifications/specifications.
A protocol supported by the current TCG specification is the so-called direct anonymous attestation (DAA) protocol which allows a host comprising a TPM to prove to a verifier, e.g., some service provider, that it possesses a certification of an issuer without either disclosing the certificate or its own identity. The mathematical background and implementation of this protocol is described in a paper by Brickell, Camenisch and Chen, titled “Direct Anonymous Attestation” presented at the 2004 ACM Conference on Computers and Communications Security.
In a nutshell, the direct anonymous attestation scheme works as follows. A TPM chooses a secret parameter, obtains a signature, called attestation in the context of this application, on it from an issuer via a secure two-party protocol, and then can convince a verifier that it got attestation anonymously by a proof of knowledge of attestation. To allow the verifier to recognise rogue TPMs, a TPM must also provide a pseudonym and a proof that the pseudonym is formed correctly, i.e., that it is derived from the TPM's secret parameter used in the attestation procedure and a base determined by the verifier.
More specifically, the TPM integrated into a host platform generates a first pseudonym NI for communication with the issuer based on the issuer's public key PKI and secret parameters f0 and f1 generated by the TPM. The TPM further computes a message U based on the same secret parameter. The TPM then authenticates the so-called direct attestation key (DAA key) comprising these two parts with an endorsement key EK also stored securely inside the TPM.
In order to obtain certification, the TPM proves to an external issuer, for example a network service provider or manufacturer of the TPM, that is possesses knowledge of the secret parameters f0 and f1 that have contributed to the generation of the DAA key without disclosing the secret parameters itself.
The issuer verifies the proof and the endorsement key EK of the TPM, for example using black- or white lists, listing valid or rogue TPMs respectively. If the issuer is convinced that the DAA key was generated by a valid TPM, it generates a certificate (A, e) that can be used to prove that the TPM possesses attestation for this particular DAA key by the issuer identified with the associated PKI. The key generation and subsequent certification by an issuer is also referred to as the join protocol.
In a further protocol, called the sign protocol, the TPM generates a further asymmetric key, called the attestation identity key (AIK) for communication with a verifier. The TPM then generates a signature σ on the AIK using the secret parameters f0 and f1 and the certificate (A, e) and transmits the signature σ and the AIK to the verifier.
In order to remain anonymous, the TPM does not sign the AIK using its endorsement key EK or uses the pseudonym NI used for communication with the issuer but uses second pseudonym NV for communication with the verifier. The pseudonym NV contains a contribution based on the secret parameters f0 and f1 stored inside the TPM and may contain a contribution based on a public key PKV of the verifier. In this way, the TPM can generate different pseudonyms for different AIKs without allowing verifiers to link these keys to one another, thus remaining anonymous.
The signature σ effectively constitutes a proof of the host to the verifier that its TPM possesses knowledge of the certificate on its secret part of the DAA key. Again, neither the key nor the secret parameters f0 and f1 used in its generation are disclosed. Finally, the verifier verifies that the signature σ on the AIK is valid and was computed based on the knowledge of the certificate (A, e) and the secret parameters f0 and f1.
However, due to its black-box implementation, users do not necessarily trust the TPM itself. Many are particularly concerned about so-called trapdoor functions, integrated into the TPM, for example, by the manufacturer or authorities such as a secret service. Such trapdoor functions could allow identification of the source of what purports to be an anonymous message.
Consequently, there exists a need for improved cryptographic methods in general and cryptographic methods for generating and using anonymous attestation keys in particular.